[Previous] [Next] [Index] [Thread]

Re: Cern HTTPD: Password/Login problems ?



Jerry Shaver wrote:
=>
=>I also am trying to use  Cern HTTPD version 3.0, and I have created a Protect
=>line in the httpd.conf file for my www root directory.
=>
=>I also get a  dialog window which asks for the password and login but any 
=>login and password I try fails.  I created the password file using htadm 
=>and have used htadm to check the password.

Hi,

  I've just been fixing this this morning for one of our external
departments, so it should still be fresh in my mind.

In setting up password control for a directory, you will have to create or
change FIVE files. These are

 1> httpd.conf <= your server configuration file
 2> The protection setup file
 3> The password file
 4> The group file
 5> .www_acl <= the access control file

Read this procedure AT LEAST ONCE before you use it. It requires some
forward planning.

I'll try and be clear and concise, without skipping bits. The best way for
me to explain is by giving an example as I go thru the bits.

Assume that we have a directory '/docs/safe/', which contains files which
we want to access using the URL of "http://somewhere/safe/*.htm". The
ServerRoot is thus '/docs/'. These files are to be restricted to a group of
users. This group we will label "team" for tracking/admin purposes. The
group "team" contains two users; 'fred' and 'bill'. 'bill' is in an unsafe
environment, so that user will only be allowed to access files from one IP
address 137.222.12.21 (which is sw.cse.bris.ac.uk).

File 1 - httpd.conf
=================

 If you wish to protect a directory, you must add a "Protect" rule to your
httpd.conf file (the file that holds your server's configuration).

This directive should be placed in your httpd.conf file BEFORE ANY PASS
rules. Given in the Cern docs is the fact that if a PASS rule is matched,
the server will NOT attempt to match any other rules.

In other words, if you have 

    PASS /*

near the start of your httpd.conf file, you will negate ANY Protect rules
that you have after it.

The format of the basic Protect rule is, in this example,

   Protect /safe/*  /usr/adm/prot-setup

where:
  /safe/*    is the URL that matches ANY file below /safe
  prot-setup is the full pathname of the 'protection setup file' that you
             want to use to describe the protection to be given to this
             directory.

NOTE:- There is another format for the Protect rule, which is

   Protect /safe/*  /usr/adm/prot-setup  uid.gid

but I'm still unsure about how to use this properly, SO......


File 2 - the protection setup file
================================

This is a text file that you create, that describes HOW you want to
protect a certain directory.

This file loks something like this:

  AuthType     Basic
  ServerID     MyProtection
  GroupFile    /usr/adm/web-group
  PasswordFile /usr/adm/web-passwd

The first line sets the authorisation type you wish to employ for this
directory.

This states that the type of authorisation that you want to server to use
is 'Basic'. I don't know if there are any other authorisation types that
you can use with Cern (any takers???).

Line two sets a labels for use when you're debugging your setup (basically).

Line 3 and 4 are the FULL pathnames of two files (yet to be created), that
contain the information about the groups of people you wish to grant web
access to, and their passwords.

File 3 - The (web) password file
==============================
   
Using the 'htadm' program, create usernames and passwords for the PEOPLE
(not the groups, that's insecure!) that you wish to grant access to. This
is (basically) done, as follows:

  htadm -create /usr/adm/web-passwd
  htadm -adduser /usr/adm/web-passwd

You must specify the FULL pathname of the (web) password file. Consult
Cern's docs for further info on using this package.

In our example, we create usernames and passwords for the users 'fred' and
'bill'.

I (me, myself, I, PERSONALLY) find it easier to create personal user
accounts BEFORE creating groups   

File 4 - The group file
=======================

This is a plaintext file that you must create, that describes the GROUPS
of people that you want to have access to your protected directories. You
can specify many groups in this file. However, groups can only access a
directory if you have EXPLICITLY granted them access to that directory
(see file 5 below).

A group file may look like this:

   authors: john, james
   trusted: authors, jim
   team: {fred , bill@137.222.12.21 }

This file creates three groups; 'authors', 'trusted' and 'team'. We do
not need to concern ourselves with 'authors' and 'trusted', we're only
interested in 'team'.

The group 'team' is made up of two members; 'fred' and
'bill@137.222.12.21'. The last of these two signifies that only a login
by 'bill' from the IP address of 137.222.12.21, will validate that user
and so grant them access to directories restricted to 'team'.

NOTE :- It is possible to make groups, such as 'team' from other groups,
         by associating them under one 'group' name, and surrounding the
         identifiers with braces '{}'. See the Cern docs for more details.

File 5 - The access control file
===============================

Within the directory /docs/safe/, we create a file called ".www_acl". This
file dictates which users have access to this directory. It looks
something like this:

 fred*.htm : GET : fred
 *.htm     : GET : fred,bill

This is the key file (I think) to the whole thing running. The server
scans this directory, finds this file and loads it.

What this example file says is that only the user 'fred' can access .HTML
files with filenames that begin 'fred' but that both 'fred' and 'bill' can
access ANY (*) .htm file in THAT directory.

There are other access methods that you can use. As usual, refer to Cern
docs for help.

Running it
==========

 Restart your server in your preferred method. I suggest running it '-v'
(verbose) to test it for a while.

NOTE
=====

1> Access that's limited by BOTH IP address and password will still ask
   for the password of a user EVEN if that user is not from within the valid
   IP domain.

Hope this helps,

Steff

: University of Bristol                            Steff.Watkins@bris.ac.uk
: URL: http://sw.cse.bris.ac.uk/  <= As mentioned in Wired 1.04
: Making a fire so big the gods will notice me again!!!




Follow-Ups: References: